查看原文
其他

记一次卑微的渗透测试

Strive 酒仙桥六号部队 2022-04-25

本文约1800字,阅读约需5分钟。
随着攻防演练愈演愈烈,弱小的我也不得不加入攻防大军的队伍里,而本篇文章就记录了某次攻防演练中的getshell历程。在这次攻防演练中,初步利用工具批量打点无果,作为团队里卑微的撕口子工具人,只能选择一个站一个站硬啃。

1
开始
又是熟悉的“开局一个后台”系列,初期重点选择没有验证码机制的后台去进行爆破:

这里目录与账号密码同时进行爆破,然而不出意外,没有任何结果:

既然爆破无果,只能再试试其他的思路。
一般URI中带#的js多为webpack模块打包。于是决定再次从前台webpack打包的js接口入手:

利用浏览器功能美化js文件,通过搜索path关键字,查找后台路由:


通过构造路径进入后台,发现大部分接口存在二次验证。直接跳转至登录页,对path路径进行多次尝试,找到个人头像上传点。
测试直接上传jpg成功后,抓包尝试修改后缀上传webshell。但发现服务端直接对上传的文件进行了重命名,此条线索终止。

随后,找到导入excel处尝试XXE:

下载模板,解压后修改其中xml文件的内容,加入payload:

上传后发现所添加的ceye平台出现了请求:

其中有http请求,说明可以下载文件:

修改payload为访问外部实体的语句:

在vps上预先放置外部实体:

开启http服务等待下载:

之后上传文件,会触发服务器请求vps下载dtd外部实体的命令,进而读取内容。另外开启ftp服务以实现文件内容外带,尝试读取/etc/passwd中的内容。
这里直接在网上寻找的脚本:
“https://github.com/ONsec-Lab/scripts/blob/master/xxe-ftp-server.rb”

尝试读取ssh key,读取成功:
“/root/.ssh/id_rsa.pub”


对主机进行端口探测,发现22端口处于filtered状态,尝试连接发现超时,考虑到时间成本,暂时放弃这条路线。


最后在个人中心处找到一个可下载的APP:


打开app发现需要登录,且抓包发现与Web端登录接口一致,放弃尝试登录绕过,直接反编译apk,找到主界面的activity:

通过adb 的am指令绕过登录界面,到达MainActivity(Android端一些APP手势密码绕过也可以利用此方法步骤,直接跳转到设置手势密码的Activity界面,通过重新设置手势密码来进行绕过,但是同样需要通过AndroidManifest.xml来查找相应的Activity名称)。
“am start {包(package)名}/{包名}.{活动(activity)名称}”

到达主界面后发现提示登录错误,仍然存在二次验证:

仔细寻找功能点。这里很累,因为如果请求没有身份认证通过,便会直接退回登录界面,需要一直利用am指令进行主页跳转:

在订单流程处找到一处上传附件的地方,发现其对后缀名进行了白名单校验,放弃。

最后发现app只有在网盘功能处,上传时不需要cookie认证,这里第一次进行上传时uri路径存在null参数,怀疑是用来获取用户昵称在服务端创建文件夹。

将null修改为admin,虽然再次成功上传,但是没有直接返回文件路径,即使找到路径也很有可能是上传到静态目录,无法对脚本文件进行解析。

虽然网盘很大概率是静态目录,但撕口子的迫切感让我不得不把握住每一次可能的机会,遂开始尝试查找路径。
在此APP下,要想查找上传路径有两种方法,一种是通过网盘在下载文件时查看是否会有文件路径,第二种就是根据上传接口去构造猜测文件路径。
当打开网盘界面时,发现在网盘加载文件列表时需要用户会话认证,没有即为空。

白茫茫的背景图,让本不富裕的我更加雪上加霜。

只能寄希望于最后一处更加渺茫的方法:猜测路径。
手工对URI逐级进行拆分:

结果拆到第二步,惊喜就出现了,没有提示404,证明文件存在:

好家伙,我直接好家伙,这居然还是system权限,花光了我一年的运气:

shell已到手,打点工具人也该撤退了。

2
总结
本文先从Web端入手进行渗透,在webpack模式下对后台查找未授权访问点,如上传跟XXE测试,测试无果后在后台发现apk安装包,转向防护相对薄弱的Android移动端进行渗透最终getshell。

因为初始目标明确,就是为了拿到webshell打开口子,所以进行渗透时都是奔着可以getshell的方式进行重点测试。

- END -

往期推荐

PHP弱类型你真的懂了吗?

pwn入门之栈入门

MYSQL另类利用方式


长按下方图片即可关注

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存